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TITLE: FINANCIAL PRODUCT ADMINISTRATION 

SYSTEM AND METHODS 

BACKGROUND OF THE INVENTION 
5 Field Of The Invention 

The present invention relates to financial products and services. More 
particularly, though not exclusively, the present invention relates to a system 
for administering financial products and methods for defining and building 
such systems. 

10 

Problems In The Art 

Financial product administration systems for use in administering 
financial products, such as pension, life insurance, and annuity products, are 
not new. In fact, such systems have reached a fairly advanced state. These 

15 information systems allow for the creation, retrieval, and updating of digital 
records concerning clients and the financial products and services provided the 
clients. This eliminates huge amounts of paper work and improves the 
integrity of the financial records. 

Although prior art financial product administration systems have 

20 enjoyed some success, they suffer fromxseveral problems and deficiencies. A 
trend in the financial services industry is to provide clients with a wide range 
of options, spanning multiple product lines. For example, one client may 
choose to purchase from a single source a life insurance contract, an annuity 
contract, and mutual funds under a defined contribution retirement plan. As 

2 5 such, the client can transcend individual financial products. However, prior 

art financial product administration systems are focused upon products, not 
clients. Such product-based systems require the entry of client information for 
each product. This results in unnecessary duplication of data entry. What is 
more, customer service suffers, as it is difficult to retrieve a consolidated 

3 0 statement of all relevant financial information for a particular client. Thus, 
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there is a need in the art for a financial product administration system that is 
focused upon the client. 

Prior art systems also suffer from an inability to easily accommodate or 
build new financial products. Adding a new product to an existing system is 
5 often labor intensive, requiring custom software coding and modification of the 
data structures. As an example, to administer a new pension product, 
programmers may need to code new user interface screens, create or modify 
database tables, and program new stored procedures for querying the 
database. Of course, this costs time and money. A need therefore also exists 
10 in the art for a financial product administration system that allows users to 
easily define and build new products, eliminating or reducing custom coding 
required. 

Another problem with prior art financial administration systems is that 
they cannot be easily ported to different countries. Because many of the 

15 characteristics or features of the system are country specific, the system 
cannot be easily deployed on a multinational or international basis. To 
illustrate, the same prior art system used to administer financial products in 
the United States cannot necessarily be easily adapted for use in Argentina. 
The United States and Argentina represent distinct user environments with 

20 different regulatory laws, currencies, languages, cultures, etc. Such 

differences have prevented others from building a system that is portable from 
one country to another. Thus, there is also a need in the art for a flexible 
financial product administration system adaptive for use in multiple countries, 
as well as a methodology for developing and operating such systems. 

25 Yet another problem with prior art financial product administration 

systems is their poor interface with general ledger accounting systems. More 
specifically, known prior art systems do not permit a user the flexibility to tie 
money movement activities or transactions with particular general ledger 
accounts. As such, there also exists a need in the art to integrate financial 

3 0 product administration systems with general accounting systems at the 
transactional level. 
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Features Of The Invention 

A general feature of the present invention is the provision of an 
improved financial product administration system which overcomes the 
problems and deficiencies found in the prior art. 
5 A further feature of the present invention is the provision of a financial 

product administration system that is focused upon the client, allowing for 
cross-product administration and improved customer service. 

A further feature of the present invention is the provision of a new 
system for defining and building financial products online, eliminating or 
10 reducing the amount of custom software coding. 

A still further feature of the present invention is the provision of a 
financial product administration system that can be easily adapted for use in 
different user environments and deployed on a multinational or international 
basis. 

15 Another feature of the present invention is the provision of a new 

method for defining and building a system for administering financial products 
suitable for use in multiple user environments and countries. 

Yet another feature of the present invention is the provision of a 
financial product administration system with multilingual capabilities, 
20 allowing the user to easily customize the user interface for a particular 
language and modify the text on particular objects in the user interface. 

A further feature of the present invention is the provision of a financial 
product administration system that integrates with general ledger accounting 
systems, providing the user the ability to tie particular money movement 
25 activities or transactions to specific general ledger accounts. 

These as well as other features and advantages of the present invention 
will become apparent from the following specification and claims. 

SUMMARY OF THE INVENTION 
3 0 The present invention includes a client-focused system for 

administering financial products. The system includes a computing device, a 
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database connected to the computing device with data concerning clients and 
financial products, software for administering the financial products, and a 
common data structure in the database that is accessible to the software in 
administering the financial products. The common data structure includes 
5 information relating to a client. This enables the system to be focused upon 
the client, allowing for cross-product administration and improved customer 
service. 

Another aspect of the present invention includes a method and means 
for defining and building new financial products online, eliminating or 

10 reducing the amount of custom software coding normally required. The 

method generally includes the steps of identifying a framework of required 
information for administering the financial product, providing a computer- 
readable medium capable of executing a system for administering the new 
financial product based upon the required information, presenting the user 

15 defining the new financial product with the framework of required 

information, and storing the required information for the new financial 
product as entered by the user in the computer-readable medium. 

Another aspect of the present invention is a means and method of 
adapting financial product administration software to meet specific language 

20 requirements of the user environment. The user or translator is allowed to 
modify the software online, providing specific translations for particular 
objects in the user interface. The method generally includes the steps of 
executing the financial administration system in a translate mode, selecting 
an object on the user interface to translate, providing a translation, and 

2 5 creating a translation file based on the translated text. This translation file is 
accessible to the system software for displaying text for the object in a 
particular language. It can be appreciated that allowing the user to enhance 
the multilingual capability of the system while online ehminates custom 
software coding normally required. Further, the system provides the user with 

30 the flexibility to customize the user interface for a particular language or 
dialect. 
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Yet another aspect of the present invention is a method of identifying 
and building a financial product administration system that is suitable for use 
in multiple user environments. The methodology generally includes the steps 
of defining a set of common core characteristics relative to the financial 
5 products that can be used in multiple user environments, and then using the 
core characteristics in the ad min istrative system. The method may also 
include the step of adding specific characteristics desired for a specific user 
environment. By way of example only, the financial products could include one 
or more of the set comprising life insurance, pensions, annuities, retirement 

1 0 plans, investment funds, mutual funds, and retirement accounts. The common 
core characteristics could include such things as age limits, money types, 
investment options, currency types, compensation, contributions, distributions, 
as well vesting types and options. 

In a preferred form, the method is directed at selecting certain features 

15 that are specific to products, contracts, policies, and investments, and are also 
consistent within one or more country. Such features are selected as part of 
the common core for developing the financial product administration system. 
Features specific to clients are also selected as part of the common core. The 
present invention is not limited, however, to the set of user environments 

2 0 comprising different countries. The method may also be employed where the 

user environment includes, for example, a language, geographical area, 
regulatory jurisdiction, legal jurisdiction, distinctive culture, distinctive 
currency, or a combination of these. Those skilled in the art will appreciate 
that defining and building a system based upon these common core 
25 characteristics enables the system to be easily ported to different user 

environments, including different countries. Any necessary customization of 
features that are specific to a particular user environment can be made after 
the system is deployed. This enables the financial administration system of 
the present invention to be multinational or international in scope. 

3 0 Still further yet, the present invention includes a system for 

administering financial products having the advantage of user-defined general 

5 
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ledger accounting. Whereas prior art systems have suffered from an inability 
to integrate with general ledger accounting systems at the transaction level, 
the present invention provides the user with the flexibility to tie particular 
money movement activities or transactions to specific general ledger accounts. 
The system is generally comprised of a computing device and software 
executed by the computing device for administering financial products. The 
system interfaces with an accounting module supporting a general ledger 
accounting system, enabling the user to tie a particular transaction to one of 
the general ledger accounts. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a diagram of the principal components of the preferred 
financial product administration system of the present invention. 

Figure 2 is a diagram illustrating the multi-tiered architecture of the 
15 present invention. 

Figure 3 is a diagram of the technical architecture and preferred 
delivery system of the present invention. 

Figure 4 is a block diagram of the database structure for the preferred 
financial product administration system of the present invention. 
20 Figure 5 is an individual client information window of the core software 

application. 

Figure 6 is a contract/policy window for an individual client in the core 
software application. 

Figure 7 is a client information window for an organization in the core 

2 5 software application. 

Figure 8 is a contract information window for the core software 
application. 

Figure 9 is a policy window for the core software application. 
Figure 10 is a bill fist window for the core software application. 

3 0 Figure 11 is a transaction history window for the core software 

application. 

6 
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Figures 12-14 show a product information window for a life product in 
the core software application. 

Figures 15 and 16 show a product information window for a pension 
product in the core software application. 
5 Figures 17 and 18 show a product information window for an annuity 

product in the core software application. 

Figure 19 is a block diagram, illustrating different layers of the core 
software application and country specific software. 

Figures 20A-D are decision trees, illustrating a preferred method for 
10 defining and building a Financial Product Administration System. 

Figure 21 is a multilingual options window of the core software 
application. 

Figure 22 is a dialogue box for use in translating the user interface of 
the core software application. 
15 Figure 23 is a translation window of the core software application. 

Figure 24 is a general ledger accounts window for the core software 
application. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

2 0 The present invention will be described as it applies to its preferred 

embodiment. It is not intended that the present invention be limited to the 
described embodiment. It is intended that the invention cover all 
modifications and alternatives which may be included within the spirit and 
scope of the invention. 
25 The financial product administration system (FPAS) of the present 

invention is a computer-based system designed for multiple product line 
administration. This includes both group and individual financial products in 
product lines such as life insurance, pension, and annuity. By way of example, 
life insurance products include term, universal fife, and unit-linked products. 

3 0 The pension product line can include both defined contribution and defined 

benefit retirement products. And annuity products can include such things as 



WO 01/75557 



PCT/US01/09632 



single premium or financed, immediate and deferred annuities. This list of 
product lines and specific products is only exemplary, not limiting the 
administrative capabilities of the FPAS of the present invention. 

As shown in Figure 1, the FPAS 10 of the present invention is designed 
5 with three principal components: a database 12, core software application 14, 
and country specific software 16. The database 12 is where the data and 
internal code to access and process the data reside. The core software 
application 14 is for data input and processing, including such items as the 
user interface and common functions (e.g., claims, charges, billing, and money 

10 transactions). The country specific software 16 includes customized features 
specific to one or more countries, such as output for billing statements, 
customer reports and letters and internal calculations. 

Figure 2 provides a high-level understanding of the multitiered 
architecture of the present invention. The inner most layers include the 

15 database 12, persistency 18 and business objects and rules 20. Outside these 
layers is an interface controller 22. Along the periphery is a layer comprising 
the core application interface 24 and gateways for the Internet 26, automatic 
teller machines (ATM) 28, and automated voice response systems(AVRS) 30. 
Local customized interfaces 32, imaging 34, other applications 36 and 

20 workflow 38 are also included in the peripheral layer. 

The technical architecture for the FPAS 10 is shown in Figure 3. The 
FPAS 10 has a client-server configuration. The user interface preferred for 
use by the client is a graphical user interface (GUI), running for example on a 
Microsoft (MS) Windows 95 or a MS Windows NT platform, that interacts with 

2 5 the user as the client front-end. The client is a 32-bit application designed to 

run MS Windows NT, which also has the compatibility to run on MS Windows 
95 platforms. Clients include workstation-based clients 40 on a local area 
network, as well as browser based clients 42 and telephone-based clients 44. 
The browser-based clients 42 connect via the Internet 26 through a 

3 0 router/firewall 45 to an Internet Web server 46. The telephone-based clients 

44 connect via an AVRS server 48. 
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An application/file server 50, database server 52 and email server 54 are 
also provided. The application/file server 50 is preferably running in MS 
Windows NT server. The database server 52 also preferably runs in MS 
Windows NT Server with a powerful relational database management system 
5 (RDBMS), such as SQL Server. Batch processing is written in MicroFocus 
COBOL and C, running on the application/file server 50. Batch processing 
may also be written in C++ or VisualBasic. 

Another router/fire wall 56 is provided for secure connection to the 
FPAS 10 through a frame relay network 58. Such a configuration provides a 
1 0 secure environment for those entities responsible for maintenance of the FPAS 
10. 

The FPAS 10 is a client-based system, one feature of the present 
invention. The client is the focal point of the system. As illustrated by the 
database structure of the FPAS 10 in Figure 3, client product and demographic 

15 information is stored in one location, which enables the client information to 
be easily shared across multiple product lines. This focus on the client, in 
contrast to a focus on the product in a product-based system, results in 
improved customer service through quicker response time. For example, the 
client-based FPAS 10 enables the user to easily access a consolidated view of 

20 all products relating to a single client. In addition, product information 

concerning a client is available for use in a variety of marketing programs. 
Other advantages of the client-based FPAS 10 include less data processing 
time and fewer data entry errors. 

Figure 3 shows the structure of relational database tables in the 

25 database 12. The term "client" is used in a broad sense, meaning both 

individuals and organizations. Organizations are a group of people, most 
likely a business. Ah organization client is not necessarily a customer. 
Examples of organization clients include banks, trusts, associations, unions, 
agencies, and brokerages. Client database tables 60 include individual client 

3 0 and organization client tables (62 and 64). 
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Figure 3 also illustrates the relationship between product tables 66, 
contract tables 68, and investment tables 70 in the database 12. Products 
supported and administered by the FPAS 10 preferably include both group and 
individual financial products for life insurance, pension, and annuities. For 
5 example, insurance coverage, retirement plans, and a savings vehicle 
purchased by the client are all financial products. 

Underneath the main product tables 66 resides the database structure 
for the core functions of the FPAS 10, namely, compensation, billing and 
financial transactions. In specific, tables for compensation and compensation 
10 history (72 and 74), billing and billing history (76 and 78), and transactions 
and transaction history (80 and 82) are located under the main product tables 
16. Although not shown in Figure 3, database tables relating to compensation, 
billing and financial transactions also have relationships to the client tables 
60. For example, compensation is paid to certain types of clients, namely, 
15 marketers. This further illustrates the client-based nature of the FPAS 10. 

A financial contract simply refers to some legal agreement between a 
business unit and a client to provide a product or service (e.g., life insurance 
contract). A contract in the FPAS 10 is built under a product. Under the 
contract database tables 68 reside plan and policy tables (84 and 86). A plan 
2 0 represents the terms of an employer's contract with its employees, and is built 
under group contracts in the FPAS 10. A member class is a specific class or 
group of employees under a group contract plan. The member class tables 88 
are built under the plan tables 84. 

A policy or account refers to a contract between a business unit and a 

2 5 client to provide service and coverage. Examples include insurance policies 

and brokerage-type accounts. Group policies are built under a member class 
and individual policies are built under contracts, as shown in Figure 3. 

Finally, information concerning investments is stored in investment 
tables 36. As illustrated by the location of the investment tables 36 in Figure 

3 0 3, multiple investments can be tied to the same product and multiple products 

can use the same investments. 

10 
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With the database structure described above, the logic or methods 
necessary to give the core software application 14 of the FPAS 10 flow and 
functionality becomes readily apparent to those skilled in the art from a 
review of the principal screen displays. Figure 5 is individual client 
5 information window 90 of the core software application 14. This window 90 
includes a plurality of information fields for displaying information concerning 
a particular client. In a client build mode, this information is entered only 
once and modified as necessary. Note that because the FPAS 10 is client- 
based, this client information is available for the administration of multiple 
10 products. 

Respecting the specific information items on the individual client 
information window 90, the name text fields and drop-down boxes 92 are used 
to identify the client by name. The marketer check box 94 indicates whether 
the client is a marketer, and if checked will enable the marketer level drop- 

15 down box 96. The marketer level drop-down box 96 provides the ability to 
assign a marketer hierarchy level to a marketer. The outsider marketer ID 
field 98 shows an marketer ID number used by an outside source, such as an 
agency or brokerage, that the core software application 14 does not assign. 
The marketer number field 100 displays the marketer number assigned by the 

20 core software application 14. The birth date field 102 displays the client's 

birth date. The application uses the client's birth date to compute the client's 
current age in the age field 104. The confirmation date field 106 displays the 
date the client's birth date is confirmed or supplied on an application. The 
language drop-down box 108 is for output purposes only and used to print 

25 documents in the appropriate language for the client and properly format 
dates, addresses, and phone numbers. The gender, marital status, and 
occupation drop-down boxes (110, 112, 114) display additional information 
about the client. The title field 116 indicates the client's business title. If the 
client is a smoker, the smoker check box 118 is checked. The smoker change 

30 date field 120 is used to indicate the date of behavior change if the client 
begins smoking or discontinues smoking. The retirement date field 122 

11 
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reflects the date the client retires from his or her job. The death date field 124 
displays the client's date of death, and the paperwork received date field 126 
shows the date when all necessary documents to pay a death claim were 
received. 

5 Additional information windows can be provided for displaying address 

and government ID (social security number) information for individual clients. 
A list of contracts and policies for each client is also provided in a separate 
contract/policy list window 128, as shown in Figure 6. Columns of information 
displayed include product name 130, policy ID 132, contract ID 134, effective 

10 date 136 and termination date 138. The product name field 130 lists all 

products under which the client has a policy. The policy ID field 132 lists all 
the client's policies, and the contract ID field 134 lists all contracts associated 
with a client. The effective date and termination date fields (136 and 138) list 
the effective dates and termination dates for all policies shown. 

15 An example of a client information window 140 for an organization is 

shown in Figure 7. In the client build mode, this information is entered into 
the system. Again, client information is only entered once, a benefit of a 
client-based system. 

As shown in Figure 7, the name field 142 represents the name of the 

2 0 organization. The alpha name field 144 is the name commonly used to refer to 

the organization. The type drop-down box 146 shows the type of organization. 
The bank routing ID field 148 is enabled and displays a bank routing ID if the 
organization is a bank. The bank routing ID is available for transmitting wire 
transfers to the bank for any clients that maintain an account at the bank. 
25 The marketer check box 150 indicates whether the client is a marketer, and 
enables the marketer level drop-down box 152. The outside marketer ID, 
marketer number, and language fields (154, 156, 158) are similar to those 
previously described for the individual client. 

Additional information windows for the organization client may include 

3 0 windows for phone, address, government ID, foreign affiliates, member lists, 
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and pay centers. A contract/policy list may also be displayed, taking 
advantage of the client-based feature of the FPAS 10. 

In addition to client screen, other principal screen displays include 
product, contract, policy, billing and transaction sareens. For purposes of 
5 illustration, the logic and flow of information in these screens will be described 
in the context of a life insurance product. Those skilled in the art can 
appreciate that the same approach can used for other product lines, such as 
pension and annuity. 

Figure 8 shows a contract information window 160 for a life insurance 

10 contract. The window 160 shows basic data about a life contract. The 
administer ID field 162 displays the identification number of the person 
responsible for handling the case in a home office. This field defaults to the 
user ID of the person entering the contract. The contract type field 164 
defaults from the product unless the product can be both and an individual 

15 and a group. The effective date field 166 is the date the contract is effective. 
The termination date field 168 is the date the contract terminates business. 
The anniversary date field 170 is the date of the contract's anniversary. 
Usually, this is based upon the contract effective date. The pre-anniversary 
date field 172 is the date for contract review before the anniversary processing 

20 takes effect, for example, when letters are sent to verify members and rate of a 
group. The contract year field 174 is based on anniversary, displaying the 
year of the contract. The age/gender rate table drop-down box 176 describes 
which age/gender rate table the system uses for the cost of insurance (COI) 
and contribution calculations. The total employees field 178 is the number of 

25 employees in a group contract. The total covered field 180 is updated after a 
policy is updated or terminated under the group. The grace period field 182 is 
the number of days allowed, after a bill is due, before the policy is considered 
lapsed. The date fields (184, 186 and 188) display the date the application 
form was received, signed and issued. The fields for waiver include ending 

3 0 period 190, ending age 192, and waiting period 194. The ending period field 
190 shows the number of days the policy can be waived of premium payments. 
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The ending age field 192 is the policyholder's attained age when the waiver 
period is no longer in effect, and the waiting period field 194 is the number of 
days the policyholder must wait before being eligible for the waiver of 
premium to begin. 

5 New contracts are entered by the user in contract build mode, which 

requires the user to enter contract information, billing status, and base rider 
information. Additional contract information windows may be provided 
concerning investments, administrative charges, fees and taxes, compensation 
splits, pay centers, plans and member classes, members lists, compensation 

10 history and rates. Pay centers are distinct from member classes, referring to a 
particular entity for handling money transactions. For example, different 
paycenters could be set up for billing employees from different states under a 
group life insurance policy. 

An example of policy window 196 for a life product is shown in Figure 9. 

15 Basic information for the life insurance policy is listed on this window. The 
effective date field 198 is the date the policy is effective. The external policy 
ID 200 is a policy number already associated with the policy that can be 
printed on any output. It is normally supplied by the group customer or 
policyholder. The eligibility date field 202 shows the date the insured client is 

2 0 eligible for life coverage. For term life insurance, the expiration date field 204 
displays the date the policy expires. This date is moved to the termination 
date upon expiration of the policy. The termination date field 206 shows the 
date on which the life coverage ends. The grace period field 208 displays the 
number of days a policyholder has to pay a premium after the due date. At the 

2 5 end of the grace period, the policy lapses or terminates. If the default box 210 

is checked, the grace period is defaulted from the product level. The death 
benefit drop-down box 212 indicates how the death proceeds are paid out at 
claim time in different options such as single sum, life income, and fixed 
income. The plan name drop-down box 214 is enabled and displays the name 

3 0 of the life insurance plan for a group contact. For a group life contract, the 

member class name drop-down box 216 is also enabled and lists the member 
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class of the insured covered as defined by the employer. The accelerated paid 
amount field 218shows the amount of death proceeds paid to the insured prior 
to death. The credit balance field 220 displays the amount of prepaid 
premium, an amount created because of an adjustment or a payment that 
5 made the total paid greater than the total amount due. The applications fields 
222, 224 and 226 are similar to those previously discussed for the life 
insurance contract. 

In addition to the policy information previously described, the required 
information includes salary history, coverage and money types. Additional 

10 information windows for a life policy can include beneficiary, investment 
direction, account value, periodic activity, reinsurance, disability and 
administrative charges. Note that to build a policy, the user must be in a 
policy/account build mode. 

Billing concerns the requesting and receiving of money from the 

15 customer. There are two primary reasons for requesting money from a 

customer for a life insurance product: (1) to pay for administration charges and 
expenses, and (2) to request premium and/or contribution payments. The bill 
list window 228 shown in Figure 10 lists all bills for a billing entity. 
Outstanding bills are those that do not have a paid date or the paid amount is 

2 o less than the total amount. The most recent bills are at the top of the list. The 

user can drill down on a particular bill to get more detailed information. The 
bill period start field 230 represents 232 shows the total amount of the bill. 
The paid amount field 234 represents the amount actually paid. 

There are several additional fields relating to bill information. The bill 
25 number field 236 displays the number of the bill assigned by the system. The 
external bill ID field 238 displays an external ID associated with the bill. The 
due date field 240 displays the date the bill is due. The billing frequency field 
242 shows how often the billing occurs (e.g. monthly, quarterly). The run date 
field 244 is the date the system is to generate the bill. The paid date field 246 

3 0 is the effective date of the last payment for the bill. The bill type field 248 

shows the type of bill run (e.g., equal, normal, or interim). The credit balance 
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applied field 250 displays a credit balance amount applied on a particular bill. 
Highlighting a bill row displays any credit balance used for that bill. If the bill 
used no credit balance to make the payment, nothing will appear in this field. 
The additions to credit balance field 252 displays the additions made to credit 
5 balance by a particular bill. Highlighting a bill row that made additions to 
credit balance displays the amount added to the credit balance. 

Credit balance information is also provided on the bill list window 228. 
The account number field 254 displays a credit balance account number 
assigned. The credit balance available field 256 displays the available credit 
10 balance money. Finally, totals in the unpaid amount field 258 and amount 

past due field 260 are also provided. Billing information may also be provided 
for contribution requests, comprehensive bill details and additional payment 
information. 

Transactions refer to the movement of money within the system. The 

15 transaction information and history may be provided on a series of information 
windows. An example of a transaction history window is shown in Figure 11. 
This window 262 allows the user to view the transactions for a policy or 
account over a given period of time. The transaction history window 262 
includes a scroll-down box with various fields. The effective date field 264 

20 shows the date a particular transaction was effective. The transaction type 
field 266 displays the sub -transaction name for this type of transaction. 
Examples include payroll contribution, interest crediting, partial pre- 
retirement withdrawal, as well as others. The money type field 268 displays 
the money type it applies for the particular transaction. Transactions in the 

25 system are processed by money type. Examples of different money types 

include sponsor COI post-tax, member contribution COI post-tax and member 
contribution post-tax. The gross amount field 270 shows the gross amount of 
the transaction. Note that a row on the transaction history window 262 can be 
suppressed by checking the SUP? box 272. As can be appreciated by those 

30 skilled in the art, more detailed information on a particular transaction can be 
attained by selecting a transaction row and drilling down to the appropriate 
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level of detail. Further, additional information may be provided regarding 
contributions, distributions, and investment transfers. 

Adding a new product to a prior art system for administering financial 
products is generally an arduous task, requiring a significant amount of 
5 customer software coding to accommodate product-specific features. For 
instance, several months could be spent in modifying an existing system to 
handle a new life product. The present invention solves this problem, 
providing an on-line product build that queries the user for a framework of 
required information about a product. The FPAS 10 includes the logic 

10 necessary to administer the new product based upon the information and 
parameters provided by the user. A method and means for defining and 
building new life, pension and annuity products is described below. However, 
those skilled in the art will appreciate that the same methodology can be 
employed to build other financial products as well, which fall within the scope 

15 of the present invention. 

A means is provided on the user interface for selecting a new product 
build. Upon activation of a menu item, push button or similar object on the 
user interface, a product build selection pop-up box (not shown) is then 
displayed. Once the product fine is selected, a product information window 

20 appears. The user then enters the information on the product information 
window to build new products or update an existing one. After data on this 
window is saved, other product windows may be accessed and the appropriate 
information and details may be entered and saved. What follows is a 
description of the product information windows for life, pension and annuity 

25 products. Additional information that may be necessary to complete a product 
build will also be discussed. 

An example of a product information window 274 for a life product is 
shown in Figure 12. The window 274 automatically displays only those fields 
that are applicable to the chosen product line, here life. Figures 13 and 14 

3 0 show the same product information window with additional information 

displayed as the user scrolls down the window. Respecting the various fields 
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on the life product information window 274 in Figure 12, the product name 
field 276 shows the unique product name. The acronym field 278 shows the 
unique abbreviation for the product. The product line field 280 identifies the 
product line of the product (e.g., life, pension, annuity). The product group 
5 field 282 is used to associate different products together when necessary. For 
example, a member company may want to package a defined contribution 
pension product with a life insurance product. The FPAS 10 treats these as 
two separate products, but the product group field 282 ties the two together 
and identifies them as a package for functions such as billing and 

10 compensation. The licensing group field 284 identifies the broad category 

under which a product is classified. A licensing group may be used to identify 
the products that a marketer is licensed to sell. The individual/group/both 
field 286 indicates whether the product may be sold to individuals, groups 
(often employers), or both. The introduction date field 288 displays the date 

15 the product was introduced to the market or a governmental agency or branch 
gave approval to sell it. The minimum age field 290 displays the minimum 
age a client must be in order to purchase this product. The maximum age field 
292 displays the maximum age a client can be to purchase this product. 

The currency type field 294 is used to designate the type of currency 

20 (e.g. pesos, dollars, pesetas, rupiah, etc.) used for the product. Policies and 
member accounts will be dominated in this currency. The annual maximum 
amount field 296 shows the annual maximum total of all contributions for all 
money types. The sum of the annual contributions made for all money types 
may not exceed the percent entered in the annual maximum percent field 298 

25 multiplied by the annual salary amount. The face rate method field 300 

determines the appropriate salary effective date to use when calculating total 
face amount. The rounding method field 302 is used to handle mathematical 
rounding occurrences during the calculation of coverage amounts, premiums, 
etc. The rate decimal precision field 304 is vised in conjunction with the 

3 0 rounding method field 302; it describes the number of digits before or after the 
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decimal to which the rate is rounded or truncated. The age calculation method 
field 306 is used in the coverage and premium calculations. 

The combined premium? Field 308 indicates whether the premium for a 
policy is combined to include the base and all riders. If this box is checked, the 
premium for a policy includes both premium for the base coverage and the 
premium for any riders. If the box is not checked, the premium for the base 
coverage of the policy will be calculated separately from any rider premium. 
Note that the combined premium? field 308 is active only when the calculated 
amount is equal to the total face. The cash value required? field 310 indicates 
whether the customer needs to pay at least the cash value portion of the 
premium in order to keep a policy in force. If the combined premium? Field 
308 is checked, then field 310 is unchecked and disabled. If the combined 
premium? field 308 is unchecked, field 310 is enabled. If the cash value 
required? field 310 is checked, the separate bill and contribution fist? field 312 
is unchecked and disabled. The separate bill and contribution list? field 312 
provides the capability to run bills and contribution lists on different 
frequencies or separately from one another. 

Referring now to Figure 13, the bill late charge amount field 314 is used 
to specify the amount to assess when bills for the product are not paid on time. 
The bill late charge percent field 316 is used to specify the percentage of the 
unpaid amount to assess when the bills for the product are not paid on time. 
The pre-ann processing period (days) field 318 indicates the number of days 
before a contract's anniversary date during which processing may need to take 
place. The anniversary premium increase? field 320 indicates whether a 
premium increase takes place at the time of an anniversary based on the 
insured's age. This field should always be checked for life products that do not 
have cash value, such as group term life. The billing pro rate? field 322 
indicates whether the product includes a prorating feature for bills. If a bill is 
prorated for a contract or policy, it means that only a partial premium, instead 
of a full premium amount, is charged for a partial period of coverage. The 
renewal GL option field 324 determines when the renewal period should start. 

19 
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The options include anniversary process, exit module, and year from contract 
effective date. The renewal GL exit module field 326 contains a drop-down of 
exit modules used specifically to determine when to post to renewal GLs. The 
contract exit modules: pre-anniversary field 328 contains a drop-down of exit 
5 modules used specifically for contract pre-anniversary processing. The 
contract exit modules: anniversary field 330 contains a drop-down of exit 
modules used specifically for contract anniversary processing. The plan exit 
modules: pre-anniversary field 332 contains a drop-down of existing modules 
used specifically for plan pre-anniversary processing. The plan exit modules: 

10 anniversary field 334 contains a drop-down of exit modules used specifically 
for plan anniversary processing. The contract prefix field 336 is used to 
indicate a prefix for a product if all contract numbers for the product should 
have a special identifier in front of them. For example, a business unit could 
decide that all contract numbers for a group term life product should begin 

15 with the letters GTL. The policy prefix field 338 is used to indicate a policy 
prefix if all policy numbers for the product should have a special identifier in 
front of them. The grace period (days) field 340 is used to indicate the number 
of days after the billing due date that a client has to pay the bill for a policy 
before a contract lapses. The expiration age field 342 indicates the age at 

20 which coverage for. a customer terminates. The term period (years) field 344 is 
used to indicate the number of years for which a policy is enforce. A minimum 
surrender amount field 346 shows the minimum amount required to be 
surrendered for a policy for this product. The amount at risk field 348 displays 
the risk amount to the company. The user should indicate the amount of 

25 coverage at risk to the life insurance company. This value is typically used to 
determine the correct reserve amounts for the block of business for this 
product. 

Referring now to Figure 14, the calculated amount field 350 indicates 
what is calculated for a life policy (e.g., premium, face value, etc.). The 
3 0 maximum # of premium modules field 352 shows the total maximum number 
of modules that can be entered for a policy. Issuing a life insurance policy in 
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•modules is an alternative to issuing as a flat face amount or as a premium 
amount. The annual premium per module field 354 is used to indicate the 
annual premium for one module of coverage. This amount is used to calculate 
the total face amount of policy level. The death interest date field 356 is used 
5 to select the value used to calculate the amount of interest paid for a death 
claim. Possible values include death date (calculate interest as of the date of 
death) and death paper date (calculate interest as of the paperwork received 
date). The automatic premium payment? field 358 is used to indicate whether 
the premium is deducted from an investment for automatic payment. The 

10 age/gender frequency field 360 indicates the frequency on which age/gender 
rates are based for the product. Valid options are annually and monthly. The 
pre-holiday processing? Field 362 indicates whether bill details and 
transaction activities, which are affected by a holiday, will process before or 
after the holiday. The waiver waiting period (days) field 364 indicates the 

15 number of days after the disability start date that the insured must wait 

before waiver of premium coverage begins. The waiver ending age field 366 
indicates the age at which waiver of premium coverage ends. The waiver 
ending period (days) field 368 indicates the number of days that the waiver of 
premium coverage is in effect after the insured meets the waiver waiting 

2 0 period requirements. The flat maximum guaranteed field 370 indicates the 

maximum face amount that is guaranteed to be issued to a customer, normally 
without evidence of insurability. The flat minimum amount field 372 is the 
minimum amount of coverage allowed to be issued for a policy under a product. 
The flat maximum absolute field 374 indicates the maximum face amount that 

25 would ever be issued to a customer. 

In addition to the various fields on the life product information window 
274, the user should also be queried to enter information regarding money 
types for the product, investments for the product, billing, transaction and 
base/rider information. Although not required, it is preferred that information 

30 and parameters relating to compensation, plan options, and death benefit 
options also be provided. As shown on Figure 12-14, windows separated by 

21 
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tabs can be built in the FPAS 10 for entering and displaying such additional 
information. 

An example of a product information window for a defined contribution 
pension product is shown in Figures 15 and 16. As it will become readily 
5 apparent from a review of the defined contribution pension product 

information window 376, many of the required fields are duplicative of those 
previously discussed for the life product information window 274. Note that 
the pay max contribution amount field 378is used to indicate the maximum 
contribution allowed by law or regulation for this defined contribution product, 

10 if applicable. The pay max contribution percent field 380 is used to indicate 
the maximum contribution percentage allowed by law or regulation for the 
product. This is typically defined as a percentage of salary of income. The 
cash value required? field 382 indicates whether a customer is required to send 
in the exact amount on periodic contribution request lists. As shown on Figure 

15 16, the plan exit modules: pre-anniversary field 384 contains a drop-down of 
exit modules used specifically for plan pre-anniversary processing. The plan 
exit modules: anniversary field 386 contains a drop-down of exit modules used 
specifically for plan anniversary processing, and the plan exit modules: vesting 
field 388 is \ised to indicate the exit module name that processes vesting 

2 0 calculations for the plan. 

In addition to the information requested on the defined contribution 
pension product information window 376, the user is also queried for 
information regarding money types, investments, billing, and transactions 
concerning the new pension product. It is also preferred that the information 
25 and parameters relating to compensation, plan options and death benefit 
options also be provided in defining or building any pension product. As 
shown in Figures 15 and 16, the defined contribution pension product 
information window 376 includes additional windows separated by tabs to 
assist the user in entering necessary information. 

3 0 An example of a product information window 390 for an annuity product 

is shown in Figure 17. Again, various of the fields on the annuity product 
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information window 390 have been previously described. As for the remaining 
fields, the annuity type field 392 is used to select the type of annuity product. 
The variable payment? Field 394 indicates whether variable payments are 
allowed on this product. For a product with the capability of having variable 
5 payments, a customer may receive different payment amounts at different 
times during the payment period. For a product without this feature, a 
customer will always receive the same payment amount for each payment 
period. The deferred notification (days) field 396 is used to enter the number 
of days before annuitization of a deferred annuity that the processor needs to 

10 be notified. The pay max contribution amount field 398 shows the maximum 
contribution allowed by law or regulation for this product, if applicable. The 
minimum amount field 400 is used to enter the minimum premium amount, if 
applicable, that may be accepted for the purchase of an annuity. The annuity 
calculation field 402 is used to select an annuity calculation method. The 

15 option selected may depend on which method was filed with the government. 
Actuarial staff should preferably be consulted as to which option to code. 

Referring now to Figure 18, the mortality table name field 404 is used to 
select the name of the mortality table used for the product. Again, actuarial 
staff should be consulted for which table is to be used in product development 

20 and pricing. The unisex male rate field 406 is used when a product blends 
male rates and female rates to determine a unisex rate. The age calculation 
method field 408 is used to select an age calculation method used in the 
calculation or determination of the annuity purchase rate. Possible values 
include exact age, age at last birthday and age at nearest birthday. The 

2 5 female setback count (years) field 410 is used if a product uses a male rate 

table to determine female rates. Typically, the female life expectancy is longer 
than the male. Some products may use a younger male rate to determine an 
older female rate. 

Additional windows should be provided to supplement the annuity 

3 0 product information window 390 for entering information relating to money 

types, billing, transactions, and benefit options. It is also preferable, but not 
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required, that that the user provide information concerning compensation, 
investments, plan options, death benefit options, interest options and 
anniversary payment options. 

In summary, once a particular product line is selected for a new 
5 financial product and the framework of required information entered by the 
user, the product is then defined and the system is ready for administration of 
the product. It can be appreciated by those skilled in the art that providing 
the logic to administer new products based upon a framework of information 
expedites the time necessary to build new products, saving significant amounts 

10 of custom software programming time. 

Another feature of the FPAS 10 of the present invention is that the core 
elements of the system remain the same throughout different financial product 
lines. That is, the same core software application 14 is used to administer 
multiple products, including life insurance, pension, and annuity products. 

15 This reduces the size of necessary systems support and administrative staff. 
Training costs are also decreased. 

Another benefit to this software architecture is that the core software 
application 14 remains virtually the same for business units operating in 
different countries. Each business unit can customize or localize the software 

20 to meet their particular needs. Not only does this approach reduce 

development costs, but also ensures worldwide consistency. To date, others 
have been unsuccessful in implementing such a system. In fact, it has been 
the conventional wisdom that deploying an FPAS on a multinational or 
international basis is unwieldy and unworkable, as the features of an FPAS 

25 are in some instances specific to a particular country or other user 

environment. However, the inventors of the present invention have overcome 
these problems, developing a methodology for defining and building an FPAS 
with the flexibility to adapt to different user environments. 

The software architecture for the FPAS 10 follows a multilayer or 

3 0 multitier solution. Different layers of the software (representing both the core 
software application 14 and country specific software 16) are shown in Figure 
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19. For purposes of illustration only, the software architecture shown in 
Figure 19 is for an FPAS with three product lines: pension, life insurance and 
annuity. In general, features that are client specific are built within the client 
layer 412. Features that are consistent across the product lines are built 
within the general sections, i.e., general product 414, general contract 416, and 
general policy 418. As for features specific to a product line, they are built 
within the product line sections (420, 422, 424, 426, 428, 430, 432, 434 and 
436). Investment features are provided in an investment section 438. Other 
features can be made available through country specific software 16, using 
custom fields 440, exit modules 442 and report modules 444. 

The inventors of the present invention have discovered features 
consistent across product lines, including age limits, currency, money types, 
investment options, billing/payment processing, transaction processing, and 
compensation processing. Product line specific features preferably include 
vesting and forfeiture allocations for pension products, base/rider information 
and reinsurance for life products, and benefit options and co-annuitant 
information for annuity products. 

A more detailed methodology for identifying common core 
characteristics of a system and selecting particular features for building an 
FPAS is illustrated in the decision tree shown in Figures 20A-D. Generally, 
the step of identifying a set of common core characteristics includes analyzing 
a plurality of features for administering financial products for a given set of 
user environments and selecting the features consistent within the set of user 
environments. Examples of user environments include country, language, 
geographical area, regulatory jurisdiction, legal jurisdiction, currency and 
culture. The decision tree in Figures 20A-D sets the user environment at the 
country level. It should be understood, however, that the same methodology 
could be easily adapted for other user environments. 

Now referring to Figures 20A, the first question is whether the new 
feature is product specific. If the feature is product specific and also consistent 
across all product lines, then the new feature is built in the general product 

25 
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line section 414 of the core software application 14. If the feature is product 
specific but not consistent across all product lines, then a series of decisions 
are made as to whether the feature is specific to a particular product line (life, 
pension, or annuity). If the feature is specific to a product line and also 
5 consistent within more than one country, then the feature is built in the 

specific product section (420, 422 or 424)of the core software application 14. If 
the feature is specific to a product line but not consistent within more than one 
country, customization of the country specific software 16 is allowed. For 
example, if the new feature is specific to the pension product line and is 

10 consistent within more than one country, then the feature is built in the 
pension product line section 420 of the core software application 14. If the 
feature is specific to the pension product line but is not consistent within more 
than one country, then the feature is built in the custom fields section 440 of 
the country specific software 16. 

15 If the new feature is not product specific, the next question is whether 

the feature is contract specific (see Figure 20B). Where the feature is contract 
specific and consistent across all product lines, the feature is built in the 
general contract section 416 of the core software application 14. Examples 
include features relating to billing status, investments, administrative 

2 0 charges, fees/taxes, compensation splits, owner/payor, plans/member class, 

member list, narratives, custom fields, compensation history, reports, pay 
centers, and rates. If the feature is contract specific but is not consistent 
among all product lines, then a series of questions relating to whether the 
feature is product line specific are answered. Again, if the new feature is 
25 specific to a product line and consistent within more than one country, the 
feature is built in the applicable contract section (426, 428 or 430) of the core 
software application 14. Otherwise, customization is provided through custom 
specific sections in the country specific software 16. Features relating to 
forfeiture allocation and unallocated accounts are often built in the pension 

3 0 product line section 42 and base/rider features are built in the life product line 
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section 428. Contract amendment features are usually applicable to the 
annuity product line section 430. 

If the new feature is neither product specific nor contract specific, then 
another set of rules is fired for policies as shown on Figure 20C. Where the 
5 feature is policy specific and consistent across all product lines, then the 
feature is built within the general policy section 418 of the core software 
application 14. Examples include features relating to owner/payor, 
beneficiary, earnings payment, investment direction, narratives, custom fields, 
periodic activity, accumulators, account value and rates. If the feature is 

10 policy specific but not consistent across all product fines, then a series of 

questions similar to those previously described for products and contracts are 
fired. The pension product line section 432 often includes features relating to 
salary history, money types, service history, vesting override, billing status, 
and administration charges. The life product line section 434 can include 

15 features relating to salary history, coverage, reinsurance, disability, billing 
status, and administration charges. The annuity product fine section 436 
often includes features concerning co-annuitant and policy amendments. 

One reaches the portion of the decision tree shown in Figure 20D if the 
new feature is not product, contract, or policy specific. In this instance, if the 

20 new feature is client specific and consistent within more than one country, 
then the feature is built in the client section 412 of the core software 
application 14. If the feature is client specific but not specific within more 
than one country, customization is provided through the custom fields section 
440 of the country specific software 16. Finally, if the new feature is 

25 investment specific and consistent within more than one country, then the 
feature is built in the investment section 438 of the core software application 
14. Otherwise, customization is allowed. 

With the benefit of this disclosure, those skilled in the art will 
appreciate that the new methodology for building an FPAS described above 

30 enables one to build a system that can be easily ported to different countries. 
Those skilled in the art will also understand that the detailed methodology 
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described above is only a preferred embodiment that can be modified to include 
different product lines, user environments, etc. Further, a feature could be 
spread across different layers of the software architecture. For example, a 
feature could be built as a default in the general product section 414 with 
5 further modifications made possible in the pension product line section 420, 
providing the system greater flexibility. All such modified methods fall within 
the scope of the present invention. 

Multilingual capabilities are often important to the success of a software 
application used worldwide. Multilingual software applications are not new. 

10 However, others have failed to allow users the ability to modify or provide new 
translations online. In the past, custom software coding and/or modification of 
the language database would be required to effect such changes. The present 
invention solves this problem, providing a means and method for translating 
the user interface of an FPAS in an online environment. The FPAS 10 of the 

15 present invention allows a particular business unit the ability to meet country 
specific language requirements. Each object of the GUI, including menus and 
menu items, can be translated. 

For a user to translate the application, the user must be included in a 
security group having this privilege. In addition, the application must be 

2 0 running in a translate mode. 

As shown in Figure 21, a multilingual options window 446 is provided 
with check boxes for multilingual enabled 448 and translate enabled 450. The 
multilingual enabled option allows the individual user to view the application 
in different languages. The translate enabled option allows an individual to 
25 run the application in a translate mode. While running under this mode, the 
user can translate text. The business unit field 452 represents the relevant 
business unit, and the language field 454 represents the language presently 
used. For example, 1 is English and 2 could be Spanish. 

In the translate mode, the user can translate objects on the user 

3 0 interface by clicking on the right mouse button while on the object and then 

selecting "translate text" from the multilingual menu (not shown). A dialog 
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box 456 will then appear, an example of which is shown in Figure 22. The 
dialog box 456 displays the original text 458, the current text 460, and 
provides a text field 462 for the new translation. At this point the user simply 
enters the new translation into the text field 462 and clicks the OK push 
5 button. The translated text is then saved in a database table. 

While in the translate mode, all changes made to the user interface are 
visible to the user. When the user finishes editing in the translate mode, the 
system creates a translation file for the particular language or dialect thereof 
modified by the user based upon the translations stored in the database. The 

10 translation file can then be deployed to a user's workstation or desktop the 
next time the user logs into the system. 

In a normal run mode, a piece of software reads the translation file to 
display the user interface in the language version corresponding to the 
business unit 452 and language 454 selected by the user. The software is 

15 preferably programmed in a computer language such as C. One reason for 

creating a translation file from the translated text stored in the database is to 
improve performance. Querying a database to update the user interface while 
in the run mode, as opposed to reading a flat file, takes more processing time 
and requires more memory. 

2 0 A similar means and method are used to translate menus and menu 

items on the user interface. A menu item translation window 464 is provided, 
as shown in Figure 23. The menu and menu items are shown in an 
expandable hierarchy format in window 466. The user selects a menu or menu 
item to translate and then enters the appropriate information in the menu text 
25 and toolbar text fields (468 and 470). Again, translations are stored in the 
database while the user is in the translate mode. Once the user exits the 
translate mode, a translation file is created. 

Others will appreciate that the translation file can be shared with other 
business units to expedite time spent in the translation process. For example, 

3 0 a business unit in Spain could first translate the objects on certain windows 

from English to Spanish, creating a translation file. An Argentine business 
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unit could then adapt the translation file to meet specific Spanish language 
requirements in Argentina. 

It is recommended that the user not be allowed to modify all language 
versions. For example, business unit=l and language=l could correspond to a 
5 particular English language version that is unchangeable. In this case, 

persons responsible for maintenance of the FPAS 10 would not be misled as to 
the identity of certain fields on the user interface. 

User-defined accounting is yet another unique feature of the present 
invention. Posting to general ledger (GL) accounts in prior art systems is 
1 0 predetermined. That is, the user has no control over which specific GL 

accounts are posted for transactions. In contrast, the FPAS 10 allows the user 
to tie particular transactions to particular GL accounts. 

The FPAS 10 creates an interface with third-party general ledger 
accounting systems to automatically post money movement activities or 
15 transactions to general ledger accounts. The SunSystems accounting system is 
a suitable third-party accounting system for use with the FPAS 10. The 
money movement activities or transactions include, but are not limited to, 
billing/payment, compensation and other transactions. 

The general ledger accounts are first created in the FPAS 10 through a 
20 general ledger accounts window. An example of a general ledger accounts 
window 472 is shown in Figure 24. The GL accounts list 474 displays the 
names or numbers of the complete general ledger account numbers. The GL 
account type field 476 identifies the type of general ledger account highlighted 
in the GL accounts list 474; examples of GL account types include asset, 

2 5 liability, expense and revenue. The GL# 478 is a pre-assigned number with no 

entry by the user required. The GL account part type field 480 assigns a value 
to each piece of the GL account number, including a unique identifier for each 
general ledger account. The GL account part name field 482 contains a 
narrative description for the GL account, and GL account part ID field 484 

3 0 displays the GL account number itself. 
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Once the GL accounts are created, the next step is to tie money 
movement activities or transactions to the GL accounts. The GL account 
number includes a unique identifier. Thus, all the user need do is associate 
the transaction with one or more GL account numbers. For example, product 
5 transaction activities, fees/taxes, compensation, and investment earning splits 
can be tied to GL accounts. Product billing/payment activities and 
compensation can likewise be tied to GL accounts. Still further yet, 
compensation history types and reductions types can be tied to GL accounts. 
This list of different money movement activities or transactions is not meant to 

10 be limiting, but is merely exemplary. 

A general description of the present invention as well as a preferred 
embodiment of the present invention has been set forth above. Those skilled 
in the art to which the present invention pertains will recognize and be able to 
practice additional variations in the methods and systems described which fall 

15 within the teachings of this invention. Accordingly, all such modifications and 
additions are deemed to be within the scope of the invention which is to be 
limited only by the claims appended hereto. 
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What is claimed is: 

1. A first ever client-focused system for administering one or more 
financial products having the advantage of cross-product administration, the 

5 system comprising: a computing device including a digital storage medium and 
a central processing unit; a database connected to the computing device and 
including data related to one or more clients and the one or more financial 
products; software in the digital storage medium and executed by the 
computing device for administering the one or more financial products; and 
10 a common data structure in the database accessible to the software in 

administering the one or more financial products, the common data structure 
comprising information relating to a client. 

2. The system of claim 1 wherein the financial product includes one or 
15 more of the set comprising life insurance, pensions, and annuities. 

3. The system of claim 1 wherein the client includes individuals and 
organizations. 

20 4. The system of claim 3 wherein the clients are either existing or 
prospective. 

5. A new method of defining or building a system for administering a new 
financial product having the advantage of eliminating or reducing custom 

2 5 software coding, the method comprising: identifying a framework of 
information for administering the new financial product; providing a 
computer-readable medium capable of executing the system for administering 
the new financial product based upon the framework of information; 
presenting a user defining or building the new financial product with the 

30 framework of information; and storing the information for the new financial 
product as entered by the user in the computer-readable medium. 
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6. The method of claim 5 wherein the new financial product is a life 
product and the framework of information includes general life, money type, 
investment, billing, transaction and base/rider information. 

5 7. The method of claim 5 wherein the new financial product is a pension 
product and the framework of required information includes general pension, 
money types, investments, billing, and transaction information. 

8. The method of claim 5 wherein the new financial product is an annuity 
1 0 product and the framework of information includes general annuity, money 

types, billing, transactions, and benefit options. 

9. The method of claim 5 wherein the computer-readable medium is a 
recordable magnetic data storage medium. 

15 

10. The method of claim 5 wherein the computer-readable medium is a 
modulated carrier signal. 

11. The method of claim 5 wherein the signal is a transmission over a global 
2 0 computer network. 

12. The method of claim 5 wherein the signal is a transmission over a 
wireless network. 

25 13. A method of adapting financial product administration software to meet 
specific language requirements having the advantage of eliminating or 
reducing custom software coding, the software having objects and menus in a 
user interface that display text specific to a particular language, the method 
comprising: executing the software on a computer-readable medium in a 

30 translate mode; selecting an object on the user interface to translate; entering 
translated text for the object; and creating a translation file with digital data 
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corresponding to the translated text; wherein the translation file is accessible 
to the software for displaying the text for the object in a particular language. 

14. The method of claim 13 wherein the menu includes menu items and the 
5 method further comprises the steps of selecting a menu item on the user 

interface to translate, entering translated text for the menu item, and creating 
a translation file with digital data corresponding to the translated text. 

15. The method of claim 14 wherein the modification of the translation file 
10 is restricted to authorized persons and entities. 

16. An article for use in administering one or more financial products 
having the advantage of multilingual communication, the article comprising: a 
computer-readable signal-bearing medium; means in the medium for executing 

15 software for administering the one or more financial products; means in the 
medium for creating a user interface for the software, the user interface 
having objects and menu items; means in the medium for allowing a user to 
translate the text in the user interface corresponding to the objects and menu 
items for a particular language; and means in the medium for creating a 

2 0 translation file for the particular language. 

17. The article of claim 16 wherein the one or more financial products 
includes one or more of the set comprising life insurance, pensions, and 
annuities. 

25 

18. The article of claim 16 wherein the medium is a recordable data storage 
medium. 

19. The article of claim 16 wherein the medium is a modulated carrier 
30 signal. 
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20. The article of claim 19 wherein the signal is a transmission over a 
global computer network. 

21. The article of claim 19 wherein the signal is a transmission over a 
5 wireless network. 

22. A method of defining, building or administering one or more financial 
products having the advantage that the administration of the one or more 
financial products can be easily ported to multiple user environments, the 

10 method comprising: (a) defining a set of common core characteristics relative to 
the one or more financial products, or to administration of the one or more 
financial products, that can be used in multiple user environments; and (b) 
using the core characteristics in an administrative system. 

15 23. The method of claim 22 further comprising: (c) adding specific 
characteristics desired for a specific user environment. 

24. The method of claim 22 wherein the common core characteristics are 
unchangeable by other than authorized persons or entities. 

20 

25. The method of claim 23 wherein the specific characteristics are 
changeable and customizable. 

26. The method of claim 22 wherein the method is practiced on a computer 
25 system. 

27. The method of claim 26 wherein the computer system is operatively 
connected to an intranet. 

30 28. The method of claim 26 wherein the computer system is operatively 
connected to a wide area network. 
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29. The method of claim 26 wherein the computer system is operatively 
connected to a global computer network. 

30. The method of claim 23 wherein the one or more financial products 

5 include one or more of the set comprising life insurance, pensions, annuities, 
retirement plans, investment funds, mutual funds, and retirement accounts. 

31. The method of claim 30 wherein the retirement plan comprises a 
defined contribution retirement plan. 

10 

32. The method of claim 30 wherein the retirement plan comprises a 
defined benefit retirement plan. 

33. The method of claim 30 wherein the retirement plan is a cash balance 
1 5 retirement plan. 

34. The method of claim 30 wherein the life insurance comprises a death 
benefit component. 

20 35. The method of claim 30 wherein the life insurance comprises a death 
benefit component and an investment component. 

36. The method of claim 26 wherein administering comprises accounting 
for, billing, paying out, notifying, reporting, compensating, processing claims, 

25 and recordkeeping relative to a plurality of clients for a plurality of financial 
products. 

37. The method of claim 37 wherein the step of defining a set of common 
core characteristics comprises analyzing a plurality of features for 

3 0 administering financial products for a given set of user environments and 
selecting the features consistent within the set of user environments. 
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38. The method of claim 37 wherein each of the one or more financial 
products is part of a particular product line, and the step of selecting features 
is performed according to the following rule: if the feature is product specific 
and consistent among all product lines, then select the feature. 

.5 

39. The method of claim 38 wherein the financial product lines include a 
pension product line, the set of user environments comprises different 
countries, and the step of selecting features is further performed according to 
the following rule: if the feature is product specific and specific to the pension 

10 product line and consistent within one or more countries, then select the 
feature. 



40. The method of claim 39 wherein the step of adding specific 
characteristics is performed by allowing for customization of the system 

15 according to the following rule: if the feature is product specific and specific to 
the pension product line and not consistent within more than one country, 
then allow for customization of the system in the countries. 

41. The method of claim 38 wherein the financial product lines include a life 
20 insurance product line, the set of user environments comprises different 

countries, and the step of selecting features is further performed according to 
the following rule: if the feature is product specific and specific to the life 
insurance product line and consistent within one or more countries, then select 
the feature. 

25 

42. The method of claim 41 wherein the step of adding specific 
characteristics is performed by allowing for customization of the system 
according to the following rule: if the feature is product specific and specific to 
the life insurance product line and not consistent within more than one 

3 0 country, then allow for customization of the system in the countries. 
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43. The method of claim 38 wherein the financial product lines include an 
annuity product line, the set of user environments comprises different 
countries, and the step of selecting features is further performed according to 
the following rule: if the feature is product specific and specific to the annuity 

5 product line and consistent within one or more countries, then select the 
feature. 

44. The method of claim 43 wherein the step of adding specific 
characteristics is performed by allowing for customization of the system 

10 according to the following rule: if the feature is product specific and specific to 
the annuity product line and not consistent within more than one country, 
then allow for customization of the system in the countries. 

45. The method of claim 37 wherein each of the one or more financial 

15 products is part of a particular product line and is associated with one or more 
contracts to provide service, the step of selecting features is performed 
according to the following rule: if the feature is contract specific and consistent 
among all product lines, then select the feature. 

20 46. The method of claim 45 wherein the financial product lines include a 
pension product line, the set of user environments comprises different 
countries, and the step of selecting features is further performed according to 
the following rule: if the feature is contract specific and specific to the pension 
product line and consistent within one or more countries, then select the 

25 feature. 

47. The method of claim 46 wherein the step of adding specific 
characteristics is performed by allowing for customization of the system 
according to the following rule: if the feature is contract specific and specific to 
3 0 the pension product line and not consistent within more than one country, 
then allow for customization of the system in the countries. 
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48. The method of claim 45 wherein the financial product lines include a life 
insurance product line, the set of user environments comprises different 
countries, and the step of selecting features is further performed according to 
the following rule: if the feature is contract specific and specific to the life 

5 insurance product line and consistent within one or more countries, then select 
the feature. 

49. The method of claim 48 wherein the step of adding specific 
characteristics is performed by allowing for customization of the system 

10 according to the following ride: if the feature is contract specific and specific to 
the life insurance product line and not consistent within more than one 
country, then allow for customization of the system in the countries. 

50. The method of claim 45 wherein the financial product lines include an 
15 annuity product line, the set of user environments comprises different 

countries, and the step of selecting features is further performed according to 
the following rule: if the feature is contract specific and specific to the annuity 
product line and consistent within one or more countries, then select the 
feature. 

20 

51. The method of claim 50 wherein the step of adding specific 
characteristics is performed by allowing for customization of the system 
according to the following rule: if the feature is contract specific and specific to 
the annuity product line and not consistent within more than one country, 

25 then allow for customization of the system in the countries. 

52. The method of claim 45 wherein the financial product lines include a 
pension product line, a life insurance product fine, and an annuity product 
line, the set of user environments comprises different countries, and the step of 

3 0 adding specific characteristics is performed by allowing for customization of 
the system according to the following rule: if the feature is contract specific 
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and not specific to the pension, life insurance or annuity product lines, then 
allow for customization of the system in the countries. 

53. The method of claim 37 wherein each of the one or more financial 
5 products is part of a particular product line and is associated with one or more 
contracts to provide service and related policies, the step of selecting features 
is performed according to the following rule: if the feature is policy specific and 
consistent among all product lines, then select the feature. 

10 54. The method of claim 53 wherein the financial product lines include a 
pension product fine, the set of user environments comprises different 
countries, and the step of selecting features is further performed according to 
the following rule: if the feature is policy specific and specific to the pension 
product line and consistent within one or more countries, then select the 

15 feature. 

55. The method of claim 54 wherein the step of adding specific 
characteristics is performed by allowing for customization of the system 
according to the following rule: if the feature is policy specific and specific to 

2 0 the pension product line and not consistent within more than one country, 

then allow for customization of the system in the countries. 

56. The method of claim 53 wherein the financial product lines include a life 
insurance product line, the set of user environments comprises different 

25 countries, and the step of selecting features is further performed according to 
the following rule: if the feature is policy specific and specific to the life 
insurance product line and consistent within one or more countries, then select 
the feature. 

3 0 57. The method of claim 56 wherein the step of adding specific 

characteristics is performed by allowing for customization of the system 
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according to the following rule: if the feature is policy specific and specific to 
the life insurance product line and not consistent within more than one 
country, then allow for customization of the system in the countries. 

5 58. The method of claim 53 wherein the financial product lines include an 
annuity product line, the set of user environments comprises different 
countries, and the step of selecting features is further performed according to 
the following rule: if the feature is policy specific and specific to the annuity 
product line and consistent within one or more countries, then select the 
10 feature. 

59. The method of claim 58 wherein the step of adding specific 
characteristics is performed by allowing for customization of the system 
according to the following rule: if the feature is policy specific and specific to 

15 the annuity product line and not consistent within more than one country, 
then allow for customization of the system in the countries. 

60. The method of claim 53 wherein the financial product lines include a 
pension product line, a life insurance product line, and an annuity product 

2 0 line, the set of user environments comprises different countries, and the step of 

adding specific characteristics is performed by allowing for customization of 
the system according to the following rule: if the feature is policy specific and 
not specific to the pension, life insurance or annuity product lines, then allow 
for customization of the system in the countries. 

25 

61. The method of claim 37 wherein one or more clients are associated with 
the one or more financial products, the set of user environments comprises 
different countries, and the step of selecting features is performed according to 
the following rule: if the feature is client specific and is consistent within one 

3 0 or more countries, then select the feature. 
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62. The method of claim 61 wherein step of adding specific characteristics is 
performed by allowing for customization of the system according to the 
following rule: if the feature is client specific and not consistent with more 
than one country, then allow for customization of the system in the countries. 

5 

63. The method of claim 37 wherein one or more investments are associated 
with the one or more financial products, the set of user environments 
comprises different countries, and the step of selecting features is performed 
according to the following rule: if the feature is investment specific and is 

10 consistent within one or more countries, then select the feature. 

64. The method of claim 63 wherein step of adding specific characteristics is 
performed by allowing for customization of the system according to the 
following rule: if the feature is investment specific and not consistent with 

15 more than one country, then allow for customization of the system in the 
countries. 

65. The method of claim 37 wherein the common core characteristics include 
age limits. 

20 

66. The method of claim 37 wherein the common core characteristics include 
money types. 

67. The method of claim 37 wherein the common core characteristics include 
25 investment types and options. 

68. The method of claim 37 wherein the common core characteristics include 
currency types. 
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69. The method of claims 37 wherein the common core characteristics 
include compensation related to marketing of the one or more financial 
products. 

5 70. The method of claim 37 wherein the common core characteristics include 
contributions and distribution types and options. 

71. The method of claim 37 wherein the common core characteristics include 
vesting types and options. 

10 

72. The method of claim 37 wherein the user environment comprises a 
language. 

73. The method of claim 37 wherein the user environment comprises a 
15 geographical area. 

74. The method of claim 37 wherein the user environment comprises a 
regulatory jurisdiction. 

20 75. The method of claim 37 wherein the user environment comprises a legal 
jurisdiction. 

76. The method of claim 37 wherein the user environment comprises a 
distinctive culture. 

25 

77. The method of claim 37 wherein the user environment comprises a 
distinctive currency. 

78. The method of claim 37 wherein the user environment comprises a 
30 combination of two or more of language, geographical area, regulatory 

jurisdiction, legal jurisdiction, distinctive culture, and distinctive currency. 
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79. The method of claim 22 further comprising activity processing of data 
related to either the clients or the financial products. 

80. The method of claim 79 wherein the activity processing is batch 
processing. 

81. The method of claim 79 wherein the activity processing is online 
processing. 

82. The method of claim 79 wherein the activity processing is transactional 
processing. 

83. The method of claim 79 wherein the activity processing is billing 
processing. 

84. The method of claim 79 wherein the activity processing is payment 
processing. 

85. A system for administering one or more financial products having the 
advantage of user-defined general ledger accounting, the system comprising: a 
computing device including a digital storage medium and a central processing 
unit; software in the digital storage medium and executed by the computing 
device for administering the one or more financial products and processing 
financial transactions relating to the one or more financial products; wherein 
one of the system is capable of interfacing with a general ledger accounting 
system with general ledger accounts, the software enabling a user to tie a 
particular transaction to one of the general ledger accounts. 

86. The system of claim 85 wherein the one or more financial products 
includes one or more from the set comprising pension, life insurance, and 
annuities. 

* 
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87. A method of interfacing a computerized system for administering one or 
more financial products with a computerized general ledger accounting system 
having general ledger accounts, the method comprising: defining a plurality of 
specific general ledger accounts; and assigning money movement activities in 
the system for administering one or more financial products with one or more 
of the specific general ledger accounts. 

88. The method of claim 87 wherein the general ledger accounts include one 
or more parts and the money movement activities are assigned to one or more 
of the parts of the general ledger accounts. 
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